Skip to content

feat(bin): scaffold jj bookmark branch step for jj-managed projects - #1945

Open
swissgrammie wants to merge 5 commits into
kunchenguid:mainfrom
swissgrammie:fm/brief-jj-support
Open

feat(bin): scaffold jj bookmark branch step for jj-managed projects#1945
swissgrammie wants to merge 5 commits into
kunchenguid:mainfrom
swissgrammie:fm/brief-jj-support

Conversation

@swissgrammie

@swissgrammie swissgrammie commented Aug 8, 2026

Copy link
Copy Markdown

Enables Jujutsu (jj) support in firstmate: ship briefs scaffold the jj bookmark branch step when a project is jj-marked.

Takes effect only when jj has been selected for a project and jjhouse is installed. All other projects (treehouse/git) keep the existing workflow, byte-identical.

The generated jj brief makes the worker verify jj/jjhouse in its own environment before creating the bookmark and reports blocked: jj tooling missing in worker environment if either is missing, because the worker pane may not inherit firstmate's PATH. The scaffold itself refuses to emit a jj step when the tooling is absent from the host PATH (a jj-managed project forbids raw git writes, so there is no runnable fallback). The registry scan reads the mode bracket only at field 3, so description text like [v2] jj migration can never flip a legacy row to jj-managed.

Fixes the Greptile review findings on this PR.

fm-brief.sh now reads the home registry's `jj` token (after the mode
bracket) and, when present, emits `jj bookmark create fm/<id>` as the
ship brief's branch step instead of `git checkout -b`. Projects without
the token keep the existing git step byte-identically; the scout and
secondmate variants are untouched.
@greptile-apps

greptile-apps Bot commented Aug 22, 2026

Copy link
Copy Markdown

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Reviews (4): Last reviewed commit: "fix(bin): make the worker verify jj tool..." | Re-trigger Greptile

Comment thread bin/fm-brief.sh Outdated
Comment thread bin/fm-brief.sh Outdated
Comment thread bin/fm-brief.sh Outdated
Comment thread bin/fm-brief.sh
The scaffold-side PATH check only proves firstmate's environment has
jj/jjhouse; the worker runs in a daemon-owned pane that does not inherit
that PATH, so a passing scaffold check could still mandate a jj bookmark
step the worker cannot run. The generated branch step now makes the
worker verify `command -v jj && command -v jjhouse` in its own
environment first and report `blocked: jj tooling missing in worker
environment` if either is missing, keeping the scaffold-side refusal as
a fast-fail. The Greptile review's fallback and bracket-position findings
were already addressed on this branch: the no-tooling path refuses with
exit 1 instead of falling back to git, and the registry scan only reads
the mode bracket at field 3. Tests cover the worker-side gate in the
generated brief and the legacy [v2] jj description row.
@swissgrammie

Copy link
Copy Markdown
Author

Thanks for the review. I verified each finding against the current branch
head and addressed the two that were still open; the other two were already
fixed on the branch after your comments were filed.

  1. Gate checks the wrong environment (P1) - fixed. The generated brief's
    first action now makes the worker verify command -v jj && command -v jjhouse in its own environment and report blocked: jj tooling missing in worker environment if either is missing, because the worker pane does
    not inherit firstmate's PATH. The scaffold-side check remains as a
    fast-fail.
  2. Fallback violates jj project policy (P1) - already fixed on the branch
    (commit after the review): the no-tooling path now refuses with exit 1
    and emits no brief; there is no git fallback. Covered by
    test_jj_token_without_tooling_refuses_scaffold.
  3. Missing jj availability gate (P1) - same root cause as chore: initialize no-mistakes gate #1; the worker
    now verifies the tooling in its own environment, and the scaffold-side
    check covers the host.
  4. Description text mimics jj annotation (P2) - already fixed on the branch:
    the registry scan only reads the mode bracket when it opens at field 3
    and stops at the bracket close, so - repo - handles [v2] jj migration
    is not misclassified. A regression test pins this exact row.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant